1. Field of the Invention
The present invention relates to microprocessor design and, more particularly, to the automatic generation of test instructions for microprocessor designs.
2. Related Art
Various electronic design automation (EDA) software tools exist for designing microprocessors and other circuitry. Such tools allow circuit designers to create and modify virtual models of the circuit being designed. A circuit designer may, for example, specify a circuit design using a textual description written in a hardware description language (HDL), such as Verilog or VHDL, or by using a graphical user interface to manipulate a graphical representation of the circuit design.
Software tools are also frequently used for testing circuit designs, such as microprocessor designs. Referring to FIG. 1, for example, a prior art microprocessor test system 100 is shown in functional block diagram form. The system includes a microprocessor design 110, also referred to as a hardware model under test or design under test (DUT). Although the microprocessor design 110 may be either an actual (hardware) microprocessor or a software (simulated) model of a microprocessor, assume for purposes of the present discussion that the microprocessor design 110 is a software model of a microprocessor.
The microprocessor design 110 models both the operation of the microprocessor (e.g., the functional relationship between inputs and outputs of the microprocessor) and the state of the microprocessor's machine resources, such as its registers, cache(s), and main memory, at a particular point in time. The microprocessor design 110 may be implemented, for example, in a data structure in the memory of a computer or in a file stored on a hard disk or other computer-readable medium.
The system 100 also includes a simulator 114, which is typically implemented as a software program. The simulator 114 simulates the operation of the microprocessor modeled by the microprocessor design 110. A significant advantage of using simulators for testing is that they may detect errors prior to the costly and time-consuming fabrication of the microprocessor itself.
The system 100 also includes a test case 102, which specifies both initial values for the (simulated) machine resources of the microprocessor design 110 and test instructions to be executed (in simulation) by the microprocessor design 110. The test case 102 may also specify the outputs that are expected to result from performing the test instructions based on the specified initial values. The test case 102 may, for example, be implemented in a file stored on a computer-readable medium or as a data structure in the memory of a computer.
The simulator 114 receives the test case 102 as an input and initializes the (simulated) machine resources of the microprocessor design 110 with the initial values specified by the test case 102. The simulator 114 then simulates execution of the instructions specified by the test case 102 on the microprocessor design 110. The simulator 114 modifies the state of the microprocessor design 110 accordingly as the simulation progresses. The simulator 114 produces simulation results 118 which indicate, among other things, whether the output produced by executing the test instructions matches the expected output specified by the test case 102.
Although a human circuit designer 116 may create the test case 102 manually, the test case 102 is typically generated automatically by a software program referred to as a random code generator 112. The random code generator 112 creates random sequences of instructions that are intended to exercise the microprocessor design 110 more thoroughly than conventional application software. The random code generator 112 may generate large numbers of test cases automatically and rapidly, thereby facilitating the testing process.
Test cases (such as test case 102) generated by random code generator 112 are typically not, however, completely random. Rather, a good random code generator generates test cases which focus on key aspects of the microprocessor design 110 while retaining enough randomness to test the microprocessor design 110 thoroughly. The circuit designer 116 may use a configuration file 108 (also referred to as a “probability file”) to exercise control over which test instructions are generated by the random code generator 112. The configuration file 108 may, for example, specify the frequencies with which different microprocessor instructions are to be simulated by the simulator 114. More specifically, configuration file 108 may include “knobs” 104. Each knob may specify one instruction or class of instructions by name and the frequency with which the instruction or instruction class should occur in the test case 102. The random code generator 112 is designed to generate test cases in which the distribution of instructions and/or instruction classes at least roughly matches the probability distribution specified by the knobs 104.
Microprocessors and microprocessor designs, such as the microprocessor design 110, typically have a performance monitoring unit (PMU) which includes event counters 106 that count the number of times that various events occur in the microprocessor design 110. Examples of events which may be counted by event counters 106 include, for example, the number of times the microprocessor's current privilege level (CPL) changes, the amount of traffic on the microprocessor's instruction translation lookaside buffer (ITLB) and/or data translation lookaside buffer (DTLB), the number of CPU cycles, the number of retired (executed and committed) null operations, the number of retired load/store operations, and the number of Level 1 and/or Level 2 cache hits and/or misses. The execution of particular test instructions, or the results produced by executing such instructions, may cause one or more events to occur. Each time a particular event occurs, the corresponding one of the event counters 106 is incremented.
When testing the microprocessor design 110 it is often desirable to thoroughly test (or “exercise”) the entire range of events. In particular circumstances, however, the circuit designer 116 may wish to focus the simulation on a particular event or events. It is difficult, however, for the circuit designer 116 to design the configuration file 108 to test (or “exercise”) the entire range of events or particular events of interest because, for example, the relationship between the execution of particular instruction sequences and the occurrence of particular events may be complex and difficult to predict. Although the circuit designer 116 may improve the extent to which the configuration file 108 exercises particular events by inspecting the event counters 106 and/or the simulation results 118 upon completion of the simulation performed by the simulator 114 and modifying the configuration file 108 manually in response, such a process is tedious, time-consuming, and not guaranteed to improve the extent to which the configuration file 108 exercises events of interest.
What is needed, therefore, are improved techniques for generating test instructions for microprocessor designs.